1. Field of the Invention
This invention relates to computer systems, and more particularly, to the identification and configuration of peripheral devices coupled to a peripheral interconnect bus.
2. Description of the Related Art
As the complexity of computer technologies grows and more, improved features are available to users of personal computers, demand for these features increases. PC (personal computer) users also demand that these features be made available at a low cost. These pressures force PC designs to use higher levels of integration throughout the system. The need for a higher level of integration may lead to the development of new types of peripheral buses and I/O (input/output) concepts.
One of the subsystems which has been targeted for increased integration is the audio/modem subsystem. Integration of the audio/modem subsystem into the motherboard by physically soldering components of the subsystem to the motherboard has been problematic because of delays resulting from certification of the modem. These problems have, in part, been addressed by development of various new specifications, including the Audio Codec ""97 (AC ""97) and the Audio/Modem Riser (AMR) Specification developed by Intel. The AMR Specification, which in some embodiments may be partly based on the AC ""97 specification, defines a hardware-scalable original equipment manufacturer (OEM) motherboard riser board and interface that supports both audio and modem functions. By physically partitioning the portion of the modem that must be certified (analog I/O) on a riser module which is separate from the motherboard, certification processes do not delay the development of the remainder of the motherboard.
Referring to FIG. 1, a typical physical configuration of an AMR card on a motherboard is illustrated. In this system, riser card 11 is plugged into an expansion slot 12 of motherboard 13. The audio/modem subsystem includes controller 14 which is mounted directly to motherboard 13, as well as codec 15 which is mounted to riser card 11. Because riser card 11 can be removed from expansion slot 12 and thereby disconnected from motherboard 13, riser card 11 can be certified without regard to motherboard 13.
While riser card 11 can be physically decoupled from motherboard 13, riser card 11 is provided and installed by the original equipment manufacturer. It is contemplated by the AMR Specification that the configuration of the audio/modem subsystem will be known and its design taken into account in the design and configuration of the motherboard, including configuration of the BIOS software. Often, however, this is not the case.
In developing the AMR Specification, it was theorized that, because end users would not change or install audio/modem riser cards themselves, there would be no need for the riser cards to be enumerated. (xe2x80x9cEnumerationxe2x80x9d refers to the process of identifying buses and devices coupled to the buses so that plug and play software can allocate the appropriate resources for the devices, install the appropriate drivers, etc. This process is employed, for example, to identify devices connected to PCI buses.) Consequently, it was expected that the audio/modem riser devices would be known at the time the BIOS was installed, and the BIOS could be programmed for the devices. The AMR Specification therefore provided no mechanism for identifying these devices.
While the riser cards are not typically changed or installed by end users, they are often installed at the last stage of the PC building process. Consequently, the BIOS code may have already been installed by the time the riser card is plugged into the motherboard and may not be programmed for the particular riser card that is installed. Since the riser card installation may be performed as part of a configuration-to-order process at a distribution depot, it is likely that the riser card which is actually installed is not the same one which is expected by the BIOS code.
Furthermore, due to the theory behind the AMR specification, peripheral buses based on this specification may lack flexibility. Plug and play devices may be difficult, if not impossible to support. Configuring a bus based on this specification must follow design rules that are already defined in the specification. Timeslots or data streams may be pre-assigned, and the system may lack the flexibility to change them. Thus, peripheral devices having new features and functionality may be prevented from being implemented on this bus, or may only operate with reduced functionality. The bus may be unable to respond adaptively to various devices coupled to it.
The problems outlined above may in large part be solved by a method and apparatus for passing device configuration information to a shared controller. In one embodiment, a host controller may be configured to read configuration from one or more peripheral devices coupled to a serial bus. The peripheral devices may include coder/decoder (codec) circuitry, and may be implemented using a riser card. The host controller may employ one or more of several different techniques in order to read configuration information from the peripheral device. The configuration information at a minimum includes a device identifier, which may identify the vendor and the function of the device. Additional information needed to configure the device to communicate over the peripheral bus may also be obtained with a read of the device, or various lookup mechanisms, such as a lookup table or a tree-like data structure. After configuration information has been obtained for each device coupled to the bus, the host controller may dynamically configure each of the devices for communication over the bus, thereby allowing the flexibility to enumerate riser cards and add new functions through peripheral devices to the computer system in which the bus is implemented.
In various embodiment, the peripheral bus may be a serial bus, such as a DSL (digital subscriber line) bus or a universal serial bus (USB). Communication across the bus may be performed in frames of data, wherein each frame includes multiple timeslots. In some of these embodiments, a timeslot within the frame may be reserved for control information for each of the devices coupled to the bus. Some devices coupled to the bus may require a certain quantity of timeslots, while other devices may require one or more timeslots having certain positions within each frame. After determining the various needs of each of the devices coupled to the bus, the host controller may then dynamically assign timeslots to each device coupled to the serial bus. Furthermore, the host controller may be configured to detect plug and play devices. Upon detecting a plug and play device, a host controller may re-assign the timeslots within a frame to each device to ensure that the plug and play device may function without interfering with the functioning of other devices coupled to the bus. In some embodiments, the host controller may also perform a reconfiguration if a device is removed from the bus, thereby allocating additional timeslots to one or more of the remaining devices.
In other embodiments, stream addressing may be used for communication across the bus. A data stream may be considered to be a special form of a timeslot. In embodiments employing stream addressing, the host controller may assign a data stream to each device. The data stream may include identification information. Each device may monitor the bus for data streams having matching identification value, and may thus read and respond to its assigned data stream when it is detected. The data within a data stream may be formatted in a manner that best suits the device to which the data stream corresponds. In addition to having a data stream dedicated to each device on the bus, an additional data stream, referred to here as a control data stream, may be formatted to convey control data for each device between the host controller and the respective devices. The host controller may assign a plurality of bit positions within the control data stream to each device, and configure the device to respond to its assigned bit positions when the control data stream is conveyed across the bus.
In various embodiments, the type of control information obtained by the host controller may include, but is not limited to, quantity and/or position of timeslots needed, data format required by the device, data width of the device (i.e. 16 bits, 32 bits, etc.), supported device modes, amount of buffer memory available in the codec/peripheral device, addressing modes (i.e. frame/timeslot addressing, stream addressing, etc.), input/output (I/O) space required on higher layer system buses, and clocking information. The reading of configuration information may in some embodiments be facilitated by the use of a serial side bus, which is independent of the actual peripheral bus. The serial side bus may be dedicated to reading configuration information and configuring devices coupled to the peripheral bus. Furthermore, some embodiments may employ a serial EPROM (erasable-programmable read-only memory) to store the configuration information.
Thus, in various embodiments, method and apparatus for passing device configuration information to a shared controller may allow a peripheral bus to be configured following the PC building process. This may allow a personal computer to support a wider range of after-market peripheral devices, and may allow an end user to reconfigure the system as the user""s needs change. The ability to dynamically configure the bus may also allow for the use of plug and play devices.